| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
It does not make sense to re-export an existing object through a hook.
On some pages both the hook and the object was imported...
It is better to use the CONFIG (previously settings) object directly
and by doing it we avoid potential errors because of conditional hooks.
|
| |
|
|
|
|
|
| |
* avoid List component repeat
* rewrite tests and CSS
* add an id to LinksWidgetItemData (previously LinksListItems) type
because the label could be duplicated
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* remove NoResults component and move logic to Search page
* add a usePostsList hook
* remove Pagination from PostsList (it is only used if javascript is
disabled and not on every posts list)
* replace `byYear` prop with `sortByYear`
* replace `loadMore` prop with `onLoadMore`
* remove `showLoadMoreBtn` (we can use `loadMore` prop instead to
determine if we need to display the button)
* replace `titleLevel` prop with `headingLvl`
* add `firstNewResult` prop to handle focus on the new results when
loading more article (we should not focus a useless span but the item
directly)
|
| |
|
|
|
|
| |
* remove searchPage prop (the consumer should handle the submit)
* change onSubmit type
* use `useForm` hook to handle the form
|
| |
|
|
|
|
| |
It removes items complexity by allowing consumers to use any label/value
association. Translations should also be defined by the consumer.
Each item can now be configured separately (borders, layout...).
|
| |
|
|
|
|
| |
The HeadingButton component was only used inside Widget component and
it is not very useful on its own so I merge the two components in a
new Collapsible component.
|
| |
|
|
|
|
|
|
| |
It makes it easier to change a route if needed and it avoid typo
mistakes.
I also refactored a bit the concerned files to be complient with the
new ESlint config. However, I should rewrite the pages to reduce
the number of statements.
|
| |
|
|
|
|
| |
Next expect a default export for pages so only those components should
use default exports. Everything else should use named exports to
reduce the number of import statements.
|
| |
|
|
|
|
| |
Using paths aliases starting with "@" can be confusing and can lead to
conflict with existings modules. I prefer to use relative paths to
avoid extra configuration in tools because of these aliases.
|
| |
|
|
|
|
|
| |
The api file in services was not really readable. So I move the types
and I also rewrite a little the fetch function.
I also rename most of the type to avoid conflict with preexisting
types (like Node) and to keep consistency.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|